Memory protection

ABSTRACT

An integrated-circuit device ( 1 ) comprises a processor ( 7 ), memory ( 13 ) for storing executable code, and memory protection logic ( 9 ). The memory protection logic ( 9 ) is configured to: determine the state of a read protection flag for a protected region of the memory ( 13 ); detect a memory read request by the processor ( 7 ); determine whether the read request is for an address in the protected region of the memory ( 13 ); determine whether the processor ( 7 ) issued the read request while executing code stored in the protected region of the memory ( 13 ); and deny read requests for addresses in the protected region if the read protection flag for the protected region is set, unless at least one of one or more access conditions is met, wherein one of the access conditions is that the processor ( 7 ) issued the read requests while executing code stored in the protected region.

This application is a continuation application from, and claims thebenefit of, U.S. patent application Ser. No. 13/924,249 to Berntsen etal., filed on Jun. 21, 2013 and also entitled “Memory Protection,”claiming priority to GB1211422.9, filed on Jun. 27, 2012, which isincorporated in its entirety herein by reference.

This invention relates to memory protection in an integrated-circuitdevice.

A microcontroller or system-on-chip device typically stores executablecode in memory. It might have stored in its memory certain code (e.g. anoperating system or firmware module) which is written by the chipmanufacturer and other code (e.g.

a software application) which is written by a customer or user. Thesewill often be stored in non-volatile memory, such as EEPROM or flash.

It can be desirable to prevent the user code or an external debugginginterface from being able to read or overwrite the code written by thechip manufacturer, while not restricting memory access for the chipmanufacturers code. This may be because the chip manufacturers codecontains trade secrets which it does not want any other party to be ableto access. It may also help prevent the inadvertent corruption of thechip manufacturer's code by bugs in the user's code.

U.S. Pat. No. 8,051,263 describes a memory protection unit thatselectively grants or denies requests for memory access according to aset of configurable memory protection attributes for a particular regionof memory. Access to the region may depend on whether an execution unitis operating in a privileged or non-privileged mode of operation.

Such a mechanism could be used to protect a region of memory containingsensitive code from being read by user code, if the user code wereexecuted in a non-privileged mode.

However, it may be possible for a malicious attacker to cause theprocessor to read the sensitive code from memory while in a privilegedmode of operation, and then to output the contents to the attacker.Moreover, not all processors support privileged and non-privileged modesof execution.

The present invention therefore takes a different approach.

From a first aspect, the invention provides an integrated-circuit devicecomprising a processor, memory for storing executable code, and memoryprotection logic, wherein the memory protection logic is configured to:

-   -   determine the state of a read protection flag for a protected        region of the memory;    -   detect a memory read request by the processor;    -   determine whether the read request is for an address in the        protected region of the memory;    -   determine whether the processor issued the read request while        executing code stored in the protected region of the memory; and    -   deny read requests for addresses in the protected region if the        read protection flag for the protected region is set, unless at        least one of one or more access conditions is met, wherein one        of said access conditions is that the processor issued the read        requests while executing code stored in the protected region.

From a second aspect, the invention provides a method of controllingmemory access on an integrated-circuit device comprising a processor andmemory for storing executable code, the method comprising:

-   -   determining the state of a read protection flag for a protected        region of the memory;    -   detecting a memory read request by the processor;    -   determining whether the read request is for an address in the        protected region of the memory;    -   determining whether the processor issued the read request while        executing code stored in the protected region of the memory; and    -   denying read requests for addresses in the protected region if        the read protection flag for the protected region is set, unless        at least one of one or more access conditions is met, wherein        one of said access conditions is that the processor issued the        read requests while executing code stored in the protected        region.

From a still further aspect, the invention provides a method ofcontrolling memory access on an integrated-circuit device comprising aprocessor and memory for storing executable code, the method comprising:determining that a read protection flag for a protected region of thememory is set;

-   -   detecting a memory read request by the processor;    -   determining that the read request is for an address in the        protected region of the memory;    -   determining that the processor issued the read request while        executing code stored in the protected region of the memory; and    -   allowing the read request.

Thus it will be seen by those skilled in the art that, in accordancewith the invention, the location of code being executed by the processorwhen it requests read access to a protected region of memory is used todetermine whether to allow the request. Requests originating from codestored outside the protected region can be denied (if the readprotection flag is appropriately set), while requests from code storedwithin the protected region itself are allowed. For many processorarchitectures, such as those from ARM (RTM), it is important that codeis able to issue data read requests to a region in which the code itselfis stored, so that the processor can access constants embedded in thecode.

The protection is enforced by the memory protection logic, which ispreferably arranged to function independently of the processor. Thememory protection logic preferably comprises hardware logic that isseparate from the processor. It can thus be less susceptible tocircumvention by malicious software code than protection which relies onprivilege modes within the processor.

The chip manufacturer can conveniently store its code within theprotected region and set the read protection flag in order to prevent acustomer's code from reading the chip manufacturer's code, whilepreserving unrestricted memory access for its own code. Other sensitiveinformation, such as configuration data, may also be stored in theprotected region.

The memory protection logic is preferably configured to allow readrequests for addresses in the protected region if the read protectionflag for the protected region is not set. This may be useful duringinitial development stages of the device and its software. Similarly,the memory protection logic is preferably configured to allow writerequests for addresses in the protected region if a write protectionflag is not set.

The memory protection logic is preferably configured to deny readrequests for addresses in the protected region if the read protectionflag for the protected region is set, unless the processor issued theread requests while executing code stored in the protected region (inwhich case, they are allowed). Such preferred embodiments have only oneaforesaid access condition. However, other embodiments may neverthelessprovide for multiple access conditions, any of which can effectivelyoverride the read protection flag; for example, a device mightconceivably allow reading of the protected region if the processorissued the read request while executing a manufacturer's boot-loaderprogram stored in ROM.

The memory protection logic can further be configured similarly todetermine the state of a write protection flag for the protected regionand to deny write requests for addresses in the protected region if thewrite protection flag for the protected region is set, unless theprocessor issued the write requests while executing code stored in theprotected region. The read protection flag may act as the writeprotection flag also, or these may be two separate flags.

In one set of preferred embodiments, this memory is non-volatile memory,such as flash. The processor may fetch code directly from thenon-volatile memory for execution, or, in some embodiments, at leastsome of the code may be cached (e.g. in volatile memory). If the devicecomprises such a cache, it will be appreciated that references herein toexecuting code stored in the protected region encompass executing acached copy of such code.

In other embodiments, the memory may be volatile memory, such as aportion of RAM reserved for executable code, and the protected region isa region of volatile memory. Executable code may be copied to suchmemory when the device powers on (e.g. from ROM or flash).Alternatively, sections of code or individual instructions may be copiedto a protected region of volatile memory as needed, when the device isin use.

The processor and memory may be connected by one or more buses. Thememory protection logic may also be connected to at least one of thesebuses. The memory protection logic is preferably configured to monitorall accesses to the memory (e.g. all read, write and instruction-fetchoperations).

The memory protection logic may determine whether the processor issuedthe read request while executing code stored in the protected region ofmemory by determining whether the address of an instruction-fetchoperation immediately preceding the memory access request was within theprotected region. The memory protection logic may be configured to set aregister on every instruction-fetch operation in accordance with whetherthe address of the fetched instruction is in the protected region ornot. The register may comprise a binary flag which is set in accordancewith whether the address of the instruction fetch is in the protectedregion or not.

The memory protection logic may be configured to use transaction-typeinformation on a memory bus to identify an instruction-fetch operation(e.g. to distinguish it from a read request). Alternatively, it may beconfigured to identify an instruction-fetch operation by determining thestate of a processor pin, or by determining the identity of busconveying the fetch instruction (e.g. in devices having separatedata-fetch and instruction-fetch buses). When using a Cortex-MOprocessor from ARM®, the memory protection logic can use the HPROT[0](Data/Opcode) signal from the Cortex-MO to distinguish between an opcodefetch and data access.

The protected region may comprise a plurality of discrete areas oraddress ranges. However, it is preferably defined by a single,continuous address range, which can simplify the implementation logic.In some preferred embodiments, the protected region is variable and isdefined by one or more addresses stored on the device, e.g. stored asconfiguration data in non-volatile memory.

The protected region may extend between a predetermined constant addressand a variable point within the memory address range. The constantaddress may conveniently be a base or end address for the memory, oreven for the whole memory address space for the device; e.g. zero(0x0000 0000). Thus the region can be specified compactly by a singlevalue stored on the device, being the address defining the variable endof the protected region within the memory.

The memory protection unit can then be configured to determine whetherthe read request is for an address in the protected region of the memoryby determining whether or not the address is between the predeterminedconstant address and the variable memory address. This operation can beimplemented using relatively few logic gates.

In embodiments in which the aforementioned protected memory region is innon-volatile memory, the device may also comprise volatile memory, suchas RAM. The memory protection logic may additionally be configured todeny read requests for addresses in a protected region of the volatilememory if a read protection flag for the protected region of thevolatile memory is set, unless the processor issued the read requestswhile executing code stored in the protected region of the non-volatilememory. In this way, a region of protected RAM may be used by codestored in the protected region of the non-volatile memory (e.g. for heapstorage) while being protected from read access by code stored outsidethe protected region. This can protect sensitive information that codewritten by the chip manufacturer may store in RAM.

Similarly, the memory protection logic may be configured to deny writerequests for addresses in a protected region of the volatile memory if awrite protection flag for the protected region of the volatile memory isset, unless the processor issued the write requests while executing codestored in the protected region of the nonvolatile memory. In this way,customer code stored in non-volatile memory outside the protected regioncan be prevented from inadvertently or maliciously changing oroverwriting volatile data belonging to code in the protected region ofthe non-volatile memory.

The non-volatile memory protection flags may act as the volatile memoryprotection flags also, or the volatile memory flags may comprise one ormore separate flags.

In any of the foregoing embodiments, the device may comprise aninterface (e.g. one or more pins) for allowing memory access by anexternal debugger or software loader. In preferred embodiments of thepresent invention, the memory protection logic is arranged to deny readrequests received via such an interface for addresses in some or allprotected regions of volatile or non-volatile memory if a debuggingprotection flag for the region is set. Protection may similarly beprovided for write access to a protected region of volatile ornon-volatile memory and/or for instruction fetches from a protectedregion.. The memory protection logic may be configured to identifymemory access requests as originating from a debugging interface bydetermining when a debugger is acting as a bus master for a memory busin the device. When the processor is a Cortex-MO from ARM®, theprocessor may use the HMASTER signal from the Cortex-MO to distinguishbetween processor core and debugger transactions.

The memory protection logic may further be configured to determine thestate of a read protection flag for a user region of memory forexecutable code. This user region may comprise part or all of the memoryadjacent to, but excluding, the protected code region in the addressspace. The memory protection logic may by configured to deny read and/orwrite requests for addresses in the user region received from adebugging interface if the read protection flag for the user region isset. In this way, a customer or other user can protect his userapplication code from unauthorised access by a third-party; e.g. forreasons of confidentiality.

In some embodiments, the device comprises integrated radio communicationlogic, such as a radio transmitter and/or receiver (i.e. aradio-on-a-chip). A firmware module comprising code implementing a radioprotocol stack may be stored in the protected region of code memory. Asoftware application which interfaces with the firmware module may bestored outside the protected region.

Embodiments of the invention may be particularly suited to devices thatdo not have a traditional operating system, but which allow a user todevelop native code for direct execution on the processor. This isbecause such devices cannot rely on an operating system to controlmemory access and to protect any confidential software libraries ormodules which the device manufacturer may have installed in the device.

In any embodiments of the invention, the read and/or write protectionflags are preferably stored in non-volatile memory. In use, the flagsmay of course be cached in a register or in RAM. A protection flag mayjust be one element in a larger set of configuration settings. It may beencoded in any suitable manner. In some embodiments each such protectionflag is stored as a binary flag or bit field.

One or more of the protection flags may be stored in aprotection-configuration region of non-volatile memory. Preferably thedevice comprises non-volatile memory control logic arranged to preventwriting to any portion of the protection-configuration region unlessthat portion is in an erased state. Preferably the non-volatile memorycontrol logic is further arranged to allow the protection-configurationregion to be erased only if a protected region of the non-volatilememory is in an erased state.

In this way, the protection flags cannot be rewritten without firsterasing any data stored in the protected region of the non-volatilememory. Sensitive executable code stored in the protected region thuscannot be read simply by resetting the read protection flag for thenon-volatile memory.

This idea is novel and inventive in its own right. Thus, from a furtheraspect, the invention provides an integrated-circuit device comprising aprocessor, non-volatile memory, non-volatile memory control logic, andmemory protection logic, wherein:

-   -   the memory protection logic is arranged to control access to a        protectable region of the non-volatile memory in dependence on        protection configuration data stored in a        protection-configuration region of the non-volatile memory;    -   the non-volatile memory control logic is arranged to prevent        writing to any portion of the protection-configuration region        unless that portion is in an erased state; and    -   the non-volatile memory control logic is arranged to allow the        protection-configuration region to be erased only if the        protectable region is in an erased state.

From another aspect, the invention provides a method of controllingmemory access on an integrated-circuit device comprising a processor andnon-volatile memory, the method comprising:

-   -   controlling access to a protectable region of the non-volatile        memory in dependence on protection configuration data stored in        a protection-configuration region of the non-volatile memory;    -   preventing writing to any portion of the        protection-configuration region unless that portion is in an        erased state;    -   allowing the protection-configuration region to be erased only        when the protectable region is in an erased state.

Features of the earlier aspects and their embodiments may be optionalfeatures of embodiments of these aspects also, wherever appropriate. Inparticular, the protectable region may be a protected region ofnon-volatile memory as previously described, and the protectionconfiguration data may comprise one or more protection flags aspreviously described.

Preferably the non-volatile memory control logic operates independentlyof the processor. It preferably comprises distinct logic gates, separatefrom the processor. In this way, a malicious or careless programmercannot execute code on the processor that bypasses the non-volatilememory control logic. The memory protection logic is similarlyindependent of the processor in preferred embodiments.

U.S. Pat. No. 6,952,778 describes a microcontroller that provides readand/or write protection for memory blocks in an embedded memoryaccording to a set of rules. These rules assign respective securitylevels to the memory blocks and are stored in a supervisory non-volatilememory. Once it has initially been programmed in accordance with an endusers requirements, the security level for a block can only be increasedunless the supervisor non-volatile memory is erased and themicrocontroller re-initialized. This results in the user-defined defaultsecurity levels being restored.

However such an approach relies on the successful restoration of thedefault security levels in order for the memory blocks to be adequatelyprotected. If an attacker were able to interfere with the process ofre-initializing the microcontroller, the contents of the memory might beleft unprotected and readable by the attacker.

Preferred embodiments of the present invention, by contrast, usededicated non-volatile memory control logic and memory protection logicto ensure that the protection configuration data can only be reset ifany sensitive information has first been erased from the device.

The non-volatile memory control logic may be configured so that the onlymechanism provided by the non-volatile memory control logic for erasingthe protection-configuration region is an instruction that erases boththe protectable region and the protection-configuration region. This maybe an instruction to erase all the non-volatile memory in the device.

If the protection-configuration region and the protectable regioncomprise different pages or erasable blocks of memory, the non-volatilememory control logic is preferably configured to erase all pages orblocks forming the protectable region before erasing any page or blockforming part of the protection-configuration region. In this way, if theerase operation is interrupted before completing, the protectionconfiguration data will still be present if the protectable region hasnot yet been fully erased, thereby continuing to provide protection.

The memory protection logic may be configured such that, when theprotection-configuration region is in an erased state, access to theprotectable region is in the highest of an ordered set of restrictionlevels. This can provide additional security by restricting access tothe protectable region by default, e.g. in case a user omits to set newconfiguration data after an erase.

By allowing writing to the protection-configuration region when it is inan erased state, the protection configuration information can be setduring manufacturing or commissioning, and during any subsequentreprogramming of the device.

The non-volatile memory control logic is preferably arranged to receivean instruction to write to a portion of the protection-configurationregion and, in response, to check that the portion is in an erased statebefore allowing the write. It may do this by reading the portion anddetermining that it is in a natural erased state for the type ofnon-volatile memory. For example, flash memory contains a binary “1” inevery bit after a page has been erased. The memory control logic maytherefore check that every bit of the portion is a “1” before allowingthe write operation. Other memory types may of course read “0” or havesome other natural erased state.

Alternatively, regions of the non-volatile memory may contain erasedstate flags that are reset when the region is erased but are set by thenon-volatile memory control logic when a first write operation isperformed into that region. In this case, the non-volatile memorycontrol logic may check one or more erased state flags before allowing awrite operation to a portion of the protection-configuration region.

The memory-protection configuration region may store one or more valuesthat define the protectable region of non-volatile memory and/or thatdefine a protected region of volatile memory as previously described. Inthis way, an attacker cannot change the definition of the protectedregion(s) without first destroying its contents.

Optional or preferred features of one aspect or embodiment describedherein may, wherever appropriate, be applied to any other aspect orembodiment.

Certain preferred embodiments of the invention will now be described, byway of example only, with reference to the accompanying drawings, inwhich:

FIG. 1 is a schematic drawing of a microcontroller embodying theinvention;

FIG. 2 is a schematic drawing showing major software components withinthe microcontroller architecture;

FIG. 3 is a schematic memory map for the microcontroller; and

FIG. 4 is a table showing decisions that the microcontroller mayimplement for protecting flash memory from unauthorized access.

FIG. 1 shows an integrated-circuit microcontroller 1 or radio-on-a-chipwhich comprises clock logic 3, which may include a resistor-capacitoroscillator and/or may receive an input from an off-chip crystaloscillator (not shown), power management circuitry 5, a processor 7(e.g. an ARM® Cortex-MO), a memory protection unit 9, RAM 11, a flashmemory controller 20, flash memory 13, radio communication logic 17, oneor more peripherals 15, and input/output circuitry 19.

These components are interconnected using suitable lines and/or buses(not shown). The microcontroller 1 may use a Harvard architecture or avon Neumann architecture. The memory protection unit 9 is arranged tointercept all memory access instructions from the processor 7 to the RAM11 and to the flash memory controller 20.

The microcontroller 1 also has a debugging interface 18 which may beused for loading data into the flash memory 13 and for debugging theprocessor 7. It does not have direct access to the RAM 11 and flash 13,but instead has to access these memories via the memory protection unit9 and flash memory controller 20.

In use, the microcontroller 1 can be connected to a number of externalcomponents such as a power supply, radio antenna, crystal oscillator,sensors, output devices, etc.

FIG. 2 shows software components that may be installed on themicrocontroller 1. Interfacing with the microcontroller 1 hardware is anoptional hardware abstraction layer 21, such as the ARM® CortexMicrocontroller Software Interface Standard. Above this sits a firmwaremodule 23 and a separate software application 27.

The firmware module 23 is a binary application comprising a number ofembedded software blocks. A radio protocol block 31 implements one ormore wireless protocol stacks. A radio event manager 33 provides accessscheduling for the radio communication logic 17 and event multiplexing.A library 35 provides shared hardware resource management and functionssuch as random number generation, configuring interrupts and priority,power management (e.g. for enabling and disabling peripherals),encryption functions, etc. A firmware manager 37 supports enabling anddisabling the firmware module, and enabling and disabling the wirelessprotocol stack.

The firmware module 23 need not be a full operating system, in that itneed not necessarily provide support for multi-threading, memoryallocation, etc.

An application interface (API) 29 for the firmware module 23 allows thesoftware application 27 to invoke functions in the firmware module 23.It may be implemented entirely using system calls. When using an ARM(RTM) processor, each API function prototype is mapped to a firmwarefunction via an associated supervisor call (SVC) number at compile time.This mapping can be provided to the developer of the softwareapplication 27 to allow the functions to be called correctly.

The firmware module 23 can communicate events to the softwareapplication 27 as software interrupts, the content of which is buffereduntil read (polled) by the software application 27. The reading is donethrough an API call (e.g. event get( ).

FIG. 3 shows how the RAM 11 and flash 13 are shared between the firmwaremodule 23 and the software application 27. The flash 13 is assignedaddresses from zero (0x0000 0000) to SizeOfProgMem for storingexecutable program code.

Another area of flash 13, which may be on its own flash page, extendsfrom MemConfigStart to MemConfigEnd and is used for storingconfiguration data for use by the memory protection unit 9. In one setof embodiments, this page extends from Ox1000 0000 to Ox1000 07ff, but,as with all the address values mentioned herein, these values may dependon the particular processor architecture being used in any givenembodiment.

The RAM 11 is assigned addresses from 0x2000 0000 upwards to 0x20000000+SizeOfRAM.

The program area of the flash 13 comprises two distinct regions eitherside of address CLENRO (code length region 0). Region 0, between zeroand CLENRO, is where the firmware module 23 is loaded. A firmwareinterrupt vector table is stored at address zero. Region 1, extendingupwards from CLENRO to SizeOfProgMem, is where the software application27 is loaded. It too can have an interrupt vector table, at addressCLENRO.

The RAM 11 similarly has a Region 0, from the base address 0x2000 000 toRLENRO, and a Region 1, extended upwards from RLENRO. RAM Region 0provides heap storage for the firmware module 23 while RAM Region 1provides heap storage for the software application 27. A call stack isshared between the firmware module 23 and the software application 27and grows downwards from (0x2000 0000+SizeOfRAM). The memory allocatedto the call stack must be big enough for the needs of both the softwareapplication 27 and the firmware module 23.

The values of CLENRO and RLENRO are stored in the memory-protectionconfiguration area of the flash memory 13.

On power up, relevant data stored in the memory protection configurationarea of flash 13 is copied to memory protection configuration registersaccessible to the memory protection logic 9. These registers arewriteable only from a hardware state machine that executes only duringpower on of the microcontroller 1, such that the only way of changingthe contents of these registers is to change the data in the memoryprotection configuration area of the flash 13.

The memory protection logic 9 is arranged to intercept all memory accessrequests (e.g. data fetch or instruction fetch operations) from theprocessor 7 to the flash memory 13 and the RAM 11. It can identify aninstruction-fetch operation from a “transaction type” on the memory bus.For every instruction fetch that the processor 7 makes from the flashmemory 13, the memory protection logic 9 updates a single-bit flag in a“firmware region” register with a “1” if the address of the fetchedinstruction is less than CLENRO and with a “0” if the address is greaterthan or equal to CLENRO.

For every data access request, the memory protection logic 9 determineswhether the source of the access request was from the firmware module 23or elsewhere by checking the value of the “firmware region” register. Itcan be configured to detect if the source of the request is the debuggerinterface 18, or a direct-memory access (DMA) unit, by determining theidentity of the active memory bus master. It also accesses the memoryprotection configuration registers to determine whether to allow or denythe access request based on the state of the “firmware region” registerand the identity of the bus master.

In some preferred embodiments, the software application 27 is deniedread and write access to flash Region 0 and to RAM Region 0. Thisprotects confidentiality for the firmware module 23 and can preventinadvertent or malicious writing by the software application 27 tomemory locations allocated to the firmware module 23, thereby increasingrobustness and security. The software application flash Region 1 mayalso be protected from read access, e.g. to protect against read backvia the external debugging interface 18.

FIG. 4 shows a decision table that the microcontroller 1 might implementfor protecting the flash memory 13 from unauthorised access. Alternativeimplementations are, of course, possible.

Two binary flags are stored in the memory-protection configurationregion of the flash memory 13 (and are copied to registers on boot up).The first, when set, prevents data read and write access to all of theprogram flash via the debugging interface 18. The second, when set,prevents data read and write access to the Region 0 flash memory byanything other than code executing from Region 0 itself. Executionaccess (i.e. instruction fetches) by the processor 7 is still allowed,even when data read access is denied.

If an attacker were able to change the data stored in thememory-protection configuration area of the flash memory 13, theprotection mechanisms could be bypassed. However, the flash memorycontroller 20 prevents writing to the memory-protection configurationarea unless it is in an erased state. Furthermore, the flash memorycontroller 20 prevents erasing of the memory-protection configurationarea unless Regions 0 & 1 of the flash memory 13 have been erased first.It uses digital logic implementing a finite state machine to enforcethese conditions.

If the flash memory controller 20 receives an instruction to write aword to an address in the memory-protection configuration area, it willfirst read the existing contents at that address and will only allow thewrite if the existing contents are all binary “1”s, indicating that thisaddress has not been written to since an erase of the memory-protectionconfiguration area flash memory. If the check fails, it will deny thewrite and may raise an exception with the processor 7.

If the flash memory controller 20 receives an instruction to erase theentire flash memory 13, it will respond by erasing the contents of flashRegions 0 and 1 first, before erasing the memory-protectionconfiguration area. For this reasons, the memory-protectionconfiguration area is preferably stored in its own erasable flash page,separate from any program areas of the flash memory 13.

The flash memory controller 20 will deny any instruction to erase justthe memory-protection configuration area.

The skilled person will appreciate microcontroller 1 may also beconfigured to prevent code executing other than in Region 0 of the flashmemory 13 from accessing important features, such as registers relatedto low-level functions of the radio communication logic 17, the powercontrol logic 5, a direct-memory access (DMA) controller, or interruptregisters.

1. An integrated-circuit device comprising a processor, memory forstoring executable code, and memory protection logic, wherein the memoryprotection logic is configured to: determine the state of a readprotection flag for a protected region of the memory; detect a memoryread request by the processor; determine whether the read request is foran address in the protected region of the memory by determining whetherthe address of an instruction-fetch operation immediately preceding thememory access request was within the protected region; determine whetherthe processor issued the read request while executing code stored in theprotected region of the memory; and deny read requests for addresses inthe protected region if the read protection flag for the protectedregion is set, unless at least one of one or more access conditions ismet, wherein one of said access conditions is that the processor issuedthe read requests while executing code stored in the protected region.2. The integrated-circuit device of claim 1, wherein the memoryprotection logic comprises hardware logic that is separate from theprocessor.
 3. The integrated-circuit device of claim 1, wherein thememory protection logic is configured to allow read requests foraddresses in the protected region if the read protection flag for theprotected region is not set.
 4. The integrated-circuit device of claim1, wherein the memory protection logic is configured to deny readrequests for addresses in the protected region if the read protectionflag for the protected region is set, unless the processor issued theread requests while executing code stored in the protected region. 5.The integrated-circuit device of claim 1, wherein the memory protectionlogic is further configured to determine the state of a write protectionflag for the protected region and to deny write requests for addressesin the protected region if the write protection flag for the protectedregion is set, unless the processor issued the write requests whileexecuting code stored in the protected region.
 6. The integrated-circuitdevice of claim 1, wherein the memory is non-volatile memory.
 7. Theintegrated-circuit device of claim 1, wherein the memory protectionlogic is configured to monitor all accesses to the memory.
 8. Theintegrated-circuit device of claim 1, wherein the memory protectionlogic is configured to set a register on every instruction-fetchoperation in accordance with whether the address of the fetchedinstruction is in the protected region or not.
 9. The integrated-circuitdevice of claim 1, wherein the protected region is variable and isdefined by one or more addresses stored on the device.
 10. Theintegrated-circuit device of claim 1, wherein the protected region ofthe memory extends between a predetermined constant address and avariable point within the memory address range, and the memoryprotection unit is configured to determine whether the read request isfor an address in the protected region by determining whether theaddress is between the predetermined constant address and the variablememory address.
 11. The integrated-circuit device of claim 1, whereinthe memory for storing executable code is non-volatile memory, and thedevice further comprises volatile memory, and wherein the memoryprotection logic is further configured to deny read requests foraddresses in a protected region of the volatile memory if a readprotection flag for the protected region of the volatile memory is set,unless the processor issued the read requests while executing codestored in the protected region of the non-volatile memory.
 12. Theintegrated-circuit device of claim 1, comprising an interface forallowing memory access by an external debugger or software loader,wherein the memory protection logic is arranged to deny read requestsreceived via said interface for addresses in one or more protectedregions of volatile or non-volatile memory if a debugging protectionflag for the region is set.
 13. The integrated-circuit device of claim1, comprising integrated radio communication logic, wherein a firmwaremodule comprising code implementing a radio protocol stack is stored inthe protected region of code memory and wherein optionally a softwareapplication which interfaces with the firmware module is stored in thememory outside the protected region.
 14. The integrated-circuit deviceof claim 1, comprising non-volatile memory and arranged to store saidprotection flag or flags in a protection-configuration region of thenon-volatile memory, wherein the device further comprises non-volatilememory control logic arranged to prevent writing to any portion of theprotection-configuration region unless that portion is in an erasedstate.
 15. The integrated-circuit device of claim 14, wherein thenon-volatile memory control logic is further arranged to allow theprotection-configuration region to be erased only if a protected regionof the non-volatile memory is in an erased state.
 16. A method ofcontrolling memory access on an integrated-circuit device comprising aprocessor and memory for storing executable code, the method comprising:determining the state of a read protection flag for a protected regionof the memory; detecting a memory read request by the processor;determining whether the read request is for an address in the protectedregion of the memory by determining whether the address of aninstruction-fetch operation immediately preceding the memory accessrequest was within the protected region; determining whether theprocessor issued the read request while executing code stored in theprotected region of the memory; and denying read requests for addressesin the protected region if the read protection flag for the protectedregion is set, unless at least one of one or more access conditions ismet, wherein one of said access conditions is that the processor issuedthe read requests while executing code stored in the protected region.17. An integrated-circuit device comprising a processor, non-volatilememory having a natural erased state, non-volatile memory control logic,and memory protection logic, wherein: the memory protection logic isarranged to control access to a protectable region of the non-volatilememory in dependence on protection configuration data stored in aprotection-configuration region of the non-volatile memory; thenon-volatile memory control logic is arranged to prevent writing to anyportion of the protection-configuration region, unless that portion isin an erased state, by being arranged to receive an instruction to writeto a portion of the protection-configuration region and to respond byreading said portion to check that said portion is in the natural erasedstate before allowing the write; and the non-volatile memory controllogic is arranged to allow the protection-configuration region to beerased only if the protectable region is in an erased state.
 18. Theintegrated-circuit device of claim 17, wherein the non-volatile memorycontrol logic and/or memory protection logic comprise logic gatesseparate from the processor.
 19. The integrated-circuit device of claim17, wherein the non-volatile memory control logic is configured so thatthe only mechanism provided by the non-volatile memory control logic forerasing the protection-configuration region is an instruction thaterases both the protectable region and the protection-configurationregion.
 20. The integrated-circuit device of claim 17, wherein theprotection-configuration region and the protectable region comprisedifferent pages or erasable blocks of memory, and the non-volatilememory control logic is configured to erase all pages or blocks formingthe protectable region before erasing any page or block forming part ofthe protection-configuration region.
 21. The integrated-circuit deviceof claim 17, wherein the memory protection logic is configured suchthat, when the protection-configuration region is in an erased state,access to the protectable region is in the highest of an ordered set ofrestriction levels.
 22. The integrated-circuit device of claim 17,arranged to store, in the memory-protection configuration region, one ormore values that define the protectable region of non-volatile memoryand/or that define a protected region of volatile memory.
 23. Theintegrated-circuit device of claim 17, wherein the protectionconfiguration data comprises a read protection flag for the protectableregion of the non-volatile memory, and wherein the memory protectionlogic is configured to: determine the state of the read protection flag;detect a memory read request by the processor; determine whether theread request is for an address in the protectable region; determinewhether the processor issued the read request while executing codestored in the protectable region; and deny read requests for addressesin the protectable region if the read protection flag for theprotectable region is set, unless at least one of one or more accessconditions is met, wherein one of said access conditions is that theprocessor issued the read requests while executing code stored in theprotectable region.
 24. A method of controlling memory access on anintegrated-circuit device comprising a processor and non-volatilememory, the non-volatile memory being of a type that has a naturalerased state, the method comprising: controlling access to a protectableregion of the non-volatile memory in dependence on protectionconfiguration data stored in a protection-configuration region of thenon-volatile memory; preventing writing to any portion of theprotection-configuration region unless that portion is in an erasedstate by responding to an instruction to write to a portion of theprotection-configuration region by reading said portion and checkingthat said portion is in the natural erased state before allowing thewrite; and allowing the protection-configuration region to be erasedonly when the protectable region is in an erased state.